Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add external RNG input #47

Closed
wants to merge 4 commits into from
Closed

Add external RNG input #47

wants to merge 4 commits into from

Conversation

chesterliliang
Copy link

External RNG

We are working on porting w3f/schnorrkel to embedded device. Merlin is one of its dependency. Embedded device always has hardware random source which is from physical noise, very secure. Meanwhile, some functions like thread_rng in rand or rand_core could not be compiled in no_std environment on thzumbv7m-none-eabi or similar. So we added a function with extra para to make it is possible to use external RNG in transcript.rs

pub fn finalize_trng(mut self,trng: &[u8]) -> TranscriptRng
    {
        let mut random_bytes = [0u8; 32];
        random_bytes.copy_from_slice(&trng[..]);

        self.strobe.meta_ad(b"rng", false);
        self.strobe.key(&random_bytes, false);

        TranscriptRng {
            strobe: self.strobe,
        }
    }

To see how the embedded porting works, you could ref wookong-dot-schnorrkel

@hdevalence
Copy link
Contributor

Hi, I think that merlin is supposed to depend only on rand_core, not rand, so the thread_rng should not be pulled in -- is there an obstacle to having the embedded hardware device implement the RngCore trait from rand_core?

@burdges
Copy link

burdges commented Aug 5, 2019

Afaik merlin has no_std support since #42 (comment) so I think this issue can be closed.

We're discussing the schnorrkel issue in w3f/schnorrkel#31

@chesterliliang
Copy link
Author

Hi Hdevalence and Burdges. Thanks for quick response. I said wrong in my comment that merlin does depend rand_core only. And I see Burdges tried to modify schnorrkel to reduced the dependence on rand. We will keep working on to see how to improve it.
However, we still prefer external RNG as a good optional choice for schnorrkel or relative ed25519-dalek. I will explain reasons in w3f/schnorrkel#31

@burdges
Copy link

burdges commented Aug 11, 2019 •
edited
Loading

I think almost anything you passed into finalize activates std prior to rand_os 2.1 rust-random/rand#859 gets deployed. In other words, merlin itself was no_std but could not previously be deployed no_std.

Also, the fixed rand_os crate only exits for rand_core 0.5 but merlin depends upon rand_core 0.4. I think your fixes go:

  • vendor merlin to upgrade the rand_core dependency, maybe using their shim (4.2?),
  • vender rand_os 1.3 as 1.4 to back port the fix, or implement the OsRng wrapper on getrandom yourself.

@burdges burdges mentioned this pull request Aug 11, 2019
Open
@hdevalence hdevalence closed this Sep 27, 2019
@burdges
Copy link

burdges commented Sep 28, 2019

Anyone who runs into this can use the RngCore5As4 workaround in w3f/schnorrkel@8150ef6

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@chesterliliang @hdevalence @burdges